【レポート】マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計 #reinvent #SID331

AWS re:Invent 2017

#セッションレポート

#アーキテクチャ

#セキュリティ

#レポート

#AWS

虎塚

2017.12.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

re:Invent 2017のセッション「Architecting Security and Governance Across a Multi-Account Strategy」(マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計) についてレポートします。時間の都合で現地参加が叶いませんでしたので、動画を視聴しました。

発表は、AWSのSam ElmalakさんとThomson ReutersのBen Woodwardさんでした。

AWS re:Invent 2017: Architecting Security and Governance Across a Multi-Account Stra (SID331) - YouTube

個人が学習目的でAWSを使うならいざしらず、エンタープライズの組織が1個のAWSアカウントですべてのシステムをホストしようとするのは無理があります。このセッションは、マルチアカウント管理のための考え方と、世界的な大企業での実例の両方を学べる、非常に興味深い内容でした。最後にはアクションプランと称して、作業用チェックリストのサンプルも紹介されました。

むかしむかし (小話)

あなたは森に住む赤ずきんちゃんで、おばあさんを訪ねていきます。ときどきオオカミに会ったり会わなかったりします。あなたは、クラウドについて噂を聞きました。数分でセットアップできて、なんでもサーバにデプロイできるそうです。

おばあさんは、いつも素晴らしいパイとクッキーを作ってくれます。おばあさんのパイとクッキーをオンライン販売するために、あなたはAWSにアカウントを作り、サーバとバスケットを設定しました。パイとクッキーを出荷し、売上が入りはじめました。

7人の小人がその話を聞きつけて、彼らが採掘しているゴールドをオンラインで売ることにしました。ついでに、Tシャツも売り始めました。

ところが、ある日突然販売が止まりました。あなたは人々が休日なのかと思いましたが、違いました。AWSセキュリティチームから、 あなたのアカウントがBitcoinのマイニングに使われている と報告がありました。サーバは停止されてしまいました。

あなたはCloudTrailを使っていませんでしたので、何が起きたのかわかりませんでしたが、とにかくアカウントを分けることにしました。パイとクッキーを売るアカウントと、Tシャツを売るアカウントです。今度はCloudTrailも有効にしました。

また売上が上がり始めました。しかし、再び販売が止まりました。ほどなくして、悪い女王があなたのアカウントに出入りしていることを突き止めました。あなたは ルートアカウントを使っていて、女王とクレデンシャルを共有していた のです。

女王はAWSアカウントを止めて、あなたが持っているすべてのリンゴを要求しました。毒を注入して、白雪姫に渡すためです。

もちろん、赤ずきんであるあなたは良い人なので、りんごを渡さないことを決めました。すると女王はすべてのアカウントを止め、CloudTrailログを消してしまいました。 あなたは破産した ので、もはやおばあさんを訪ねる時間はありません。いったいどうやって末長く幸せに暮らせばよいのでしょうか。

このセッションで学ぶこと

さて、破産したり誰かに情報を盗まれたりしないように、次のことを学びましょう。

エンタープライズ向けのマルチアカウントのフレームワーク
戦略を実装するためのアクションプラン

AWSアカウント

AWSアカウントは、emailとパスワードを使ってセットアップします。各アカウントは、次の事項について高いレベルで分離されています。

セキュリティとリソースの境界 は、アカウントが違えば完全に分離される。
APIの実行回数の制約やスロットリング は、アカウントごとに設定される。
料金請求 もアカウントごとにおこなわれる。
- ネットワークトラフィックは、リソースへのタグ付けで分離できない。請求を完全に分離する唯一の方法は、アカウントを分けること。

もし1つのアカウントしか使っていなければ、これらは分離できません。

アカウントモデル

多くの顧客は、1個のAWSアカウントから始めます。一方で、数千のアカウントを持つ顧客もいます。そして、多くの顧客は、その中間規模の量のアカウントを持っています。

アカウントの数が多くなればなるほど、アカウント管理もデータの分配も難しく、複雑になります。

なぜ1個のアカウントでは不十分か

1個のアカウントだけを使用する状態は危険です。人々は他の人の設定を上書きしたり、他の人が使っているインスタンスを削除したり、クレデンシャルを漏洩させたり、githubにコミットしてしまったりします。

複数のチームがある場合、それぞれのチームは異なる責任とビジネスモデルを持っているため、分離が必要。
データ保存の管轄や準拠するコンプライアンスモデルが、チームによって異なる場合がある。
1つのアカウントですべてを管理する時、すべてのデータを暗号化しようと考えるかもしれないが、インターネットに公開するサービスを持っている場合、すべてのデータを暗号化するのは適切でない。
複数のチームは、異なるビジネスプロセスを持つ。
何にいつどれくらい使ったかの請求情報を分離する必要がある。

ケーススタディ: Thomson Reuterのマルチアカウント戦略

(08:00-)

Thomson Reutersは、世界規模の企業です。税金、法律、金融のプロフェッショナルに情報と商品を提供しています。100カ国以上に組織を持ち、12,000人以上の技術系専門職を抱えています。

つまり、 12,000人以上がAWSアカウントにアクセスする必要がある状況 とお考えください。スケール性と適切な運用が必要です。

データセンターとの接続

AWSとオンプレミスのデータセンターとの接続には複数のDirect Connectを利用しています。Thomson Reutersのシステムは、自社ビジネスユニットから大量のアクセスを受けています。

AWSリージョン
- データの物理的な格納場所: 新しく制定される法律に準拠する必要あり
- 新しい成長機会: 素早くマーケットにデプロイする必要あり
- レイテンシー: 最小限に抑えたい。
AWSアカウント
- プロジェクトごとの分離: コンプライアンス準拠、センシティブなデータの保護
- AWS APIの制約: システムごとに設定したい
- 請求の分離: タグ付けできないリソースも含め分離して管理

上のような事項を考慮しつつ、データセンターを何箇所接続するか、リージョンを何個使うか、アカウントを何個作るかなどを決めています。

ネットワークトポロジー

スケール性の観点からネットワークを見てみましょう。アカウント数の膨張や、ネットワークの要求、Amazonによって設定されているハードリミットも考える必要があります。

Thomson Reutersのネットワークでは、データセンターとビジネスユニットの接続にAWS Direct Connectを利用しています。現時点では50アカウントをDirect Connectで利用できます。顧客管区用との接続にはVPNを利用しています。ここにも、実際の接続数にはVPNソフト等の制約があります。また、VPC同士の接続に、VPCピアリングも利用しています。これは共有サービスやセキュリティツールのために重要です。ここにも、接続できるVPC数に制約が存在します。

このようにスケール性が要求されるため、戦略を進化させながら、新規アカウントをオンデマンドに作成する必要があります。コストやオーバーヘッド、いくつかの制約を克服して、アカウントがボトルネックにならないようにしなければなりません。

アカウントの作成

新しいアカウントは、コンソールから手作業で作ることもできますが、幸いOrganizations APIを使ってプログラムから作ることができます。Thomson Reutersでは、次のようにしています。

Organizationsアカウントから、APIを利用して新規アカウントを作成する。
Organizationsアカウントから、新規アカウントのクロスアカウントRoleを使用する。(Assume)
Organizationsアカウントから、新規アカウント内をセットアップする。たとえば、VPCのプロビジョニングなどの基本的なネットワークレイヤーを作成する。
新規アカウントをOrganizationsアカウントのOU (organizational unit) に移動する。これで、新規アカウントをグループ化して (たとえばビジネスユニットごとに) 扱うことができる。
最後に、Organizations Roleを削除する。特権アカウントとして多くの権限を持っているため。

この方法を採用したのは、次の理由によります。

アカウント作成のセルフサービス化：自動化できるところは自動化して、注力すべきところに集中
サービスコントロールポリシー (SCPs) の利用: アクセス権限を集中的に制御

アカウントのインフレーション

増え続けるアカウントに対して、次のことをします。

rootのクレデンシャルを大切に保管する
サービスマネジメントの記録を作成する
コーポレートアイデンティティプロバイダーとフェデレーションで連携する
- 初期オペレーションロールを作成
VPCとネットワークを設定する
- AWS Direct ConnectとVPCピアリングを使う
セキュリティ制御レイヤーとロギングを設定する
- ロギングの有効化、セキュリティと管理用IAM Roleの作成

ポイントは、次のとおりです。

ワークフローツールを使おう
- 異なる種類のアカウントを作成する際、各アカウントで何をデプロイする必要があるかを明示すると便利
環境をCloudFormationで動的に構築しよう
- 新しいAZが追加された時などに対応できるように、静的なテンプレートやハードコーディングを避ける
Configurationドリブンにする
- 手動で設定変更をせず、単一のconfig fileを管理することに集中する

エンタープライズに必要なアカウント群

エンタープライズ企業がAWSアカウント管理をはじめたその日に、すぐ作成する必要があるアカウントについて見ていきましょう。

ロギングアカウント

さて、上のような新規アカウントの作成プロセスができたら、エンタープライズのアカウント群を構築しはじめることができます。

まず必要なのは、 ロギング用アカウント です。このアカウントは、CloudTrailのログ、VPC Flow LogsやS3バケットのアクセスログなどを保管するために使います。

共有サービス用アカウントやセキュリティツール用アカウントで取得したログを、ロギング用アカウント一箇所に集約しましょう。

正とする唯一のソースとして、ロギング用アカウントを扱う
セキュリティ確保のために一箇所に限定する
このアカウントへのアクセスは厳しく制限する
- 一度設定を終えたら、このアカウントに誰もアクセスできないようにする
ログ保存には、環境やビジネスユニットに応じて複数のS3バケットを使う
セキュリティツールなどがログを必要とした時に、S3バケットにread-onlyのアクセス許可を与える

管理者アカウント

管理者アカウントを作成する際の方針は、次のとおりです。

たとえ開発者を信頼していても、かならず検証する
すべてのアカウントを横断的・一元的に管理する手段が必要

AWS Trusted AdvisorやAWS Configを使いましょう。何か起きた時にアクションを強制するよりも、通知するようにします。また、管理者アカウントとその他のアカウントには、read-onlyとreadwriteのIAM Roleをそれぞれ作成し、管理者アカウントからAssumeRoleで利用しましょう。

管理者アカウントは、個々のアカウントを可視化し、ハブとして機能します。

セキュリティアカウント

SecOpsのためのセキュリティアカウントを用意しましょう。このアカウントでは次のことをします。

ログの処理: ロギングアカウントからログを取得
セキュリティツールのホスト
インシデント管理

共有サービス用アカウント

エンタープライズに最低限必要な最後のアカウントは、共有サービス用アカウントです。元は、共有ネットワークサービスのために設計しました。このアカウントでは次のことをします。

AWS Direct Connect
DNSサービス
踏み台ホスト
ネットワーク監視
AMIの作成

このアカウントへアクセスする必要があるユーザは、時間がたつとともに増えますので、次の方針を守りましょう。

ビジネス的に重要なサービスは分離しましょう
より制限されたアクセスを提供しましょう

これは、障害が発生した際の影響を局所化することにつながります。

ビジネスユニットに必要なアカウント群

次に、ビジネスユニットごとに用意するアカウント種別を見ていきましょう。

サンドボックスアカウント

まず、ビジネスユニットごとのサンドボックスアカウントを用意します。

チームが新しいことを試すための場として
データセンターと接続しない
マルチテナント
権限を制限する: 多くのリソースを同じビジネスユニットのメンバー間で共有するため
既存のアカウント追加の仕組みに載せる

しかし、このようなサンドボックスに対して、開発者から、先に紹介したアカウント作成手順で自動設定される基本的なネットワークレイヤー、たとえばVPCやルーティングテーブルにも学習のためにアクセスしたいというフィードバックがあるかもしれません。

そこで、開発者ごとのサンドボックスアカウント も用意します。これは12,000人の技術専門職がいたら、12,000個のアカウントを作成することを意味します。もちろん大量のアカウントになりますが、この環境は個々の開発者の学習と実験のために必要です。

学習と実験のための場として
データセンターと接続しない
シングルテナント
フルパーミッション
最小のアカウント追加の仕組みに載せる
- マスターアカウントのconsolidated billing下に入れる

SDLC (Software Development Life Cycle) アカウント

SDLCアカウントは、ビジネスアプリケーションをビルドしてデプロイするためのアカウントです。

昨年の本セッションでは、ビジネスユニットごとに、本番アカウントと非本番アカウントの2個のアカウントを用意することを提案しました。各開発者には、非本番環境のreadwriteアクセス権を与え、本番環境のread-onlyアクセス権を与える想定でした。しかし、この設定では、誰かが想定外の変更をしうることが分かりました。

今年のセッションでは、非本番環境をDev、本番環境をProdに変更した上で、本番にデプロイする前にテストするための Staging アカウントとビジネス継続性のための Disaster Recovery アカウントを加えた4個のアカウントを用意することを提案します。最悪の事態が起きた時に、本番環境にログインして課題を分析したり、変更を元に戻したりする必要がないようにして、単にフェールオーバーすればよい状態にするためです。

各アカウントは、同様のアカウント作成プロセスにしたがい、次のように設定します。

rootのクレデンシャルを大切に保管する
基本的なネットワーク構成をプロビジョニングする
セキュリティ制御の設定をする
IAMフェデレーションを使用する
基本のIAM Roleを作成する

方針は、次のとおりです。

小さなアカウントセットから開始して、各ビジネスユニットと会話を続ける
- どんな新しいアプリケーションがリリース予定で、どんな環境が必要かを確認しよう
- どんなユースケースが将来必要かを確認しよう
必要とされるリソース分離の種類を特定する

IAMを使ったマルチテナントリソースの分離

次の方針を用います。

IAMでリソースの分離を提供する
タグによる条件式とリソース名をIAMポリシーに設定する
- 例: 特定のアプリケーション名をタグに設定されたEC2に対して、TerminateInsntances APIの使用を禁止する
- 例: 特定のアプリケーション名を名前に設定されたIAM Roleに対して、PassRoleアクションを許可する

これには、オーバーヘッドが発生することと、(タグベースのアクセス制御をサポートするAWSサービスにしか使えない戦略であるため) 100%の網羅性はないという欠点があります。

しかし、一度ポリシーを作成して、従業員用のテンプレートを定義すれば、その後は簡単に設定を管理できます。

CI/CD アカウント

CI CDアカウント

各ビジネスユニットのために作成する最後のアカウントは、CI/CD用アカウントです。SDLCアカウントの紹介で見てきたようにDev, Staging, Prodなどのアカウントがあるとして、それらのどこにCI/CDパイプラインを置くかは難しい問題です。デプロイのために環境をまたぐ設定が必要ですが、アクセス制御は厳格にしたいからです。そこで、CI/CD用アカウントを用意し、次のことをします。

CI/CDパイプラインをホストする
カオスエンジニアリング (アプリケーションの自動復旧テスト) を稼働させる

CICDアカウントには、ビルド成果物 (アーティファクト) を保存するデータストアと、ビルドパイプラインをプロビジョニングします。各SDLCアカウント (Dev, Staging, Prod) には、デプロイ用のIAM Roleを用意します。

CICDアカウントでアーティファクトをビルドする
各SDLCアカウントに次のことをする
1. AssumeRoleを使ってアクセスする
2. CloudFormationで環境をデプロイする
3. CodeDeployでアプリケーションをデプロイする

アカウント管理の開始地点

Where we started

昨年に紹介した構成では、Organizations Masterアカウントの下で、エンタープライズアカウントとしてセキュリティアカウントと共有サービス用アカウントがあり、ビジネスユニットアカウントとしてサンドボックス、Dev, Prodアカウントがありました。

Thomson Reutersではその後の教訓から、まず、エンタープライズアカウント群として、ログを一元管理するための ロギングアカウント と、横断的な管理を提供するための 管理者アカウント を追加することを提案します。さらに、 Direct Connect用アカウント と DNS用アカウント も追加することで、障害を局所化できます。

次に、ビジネスユニットアカウント群として、より本番に近い環境でテストするための Stagingアカウント と、最悪のシナリオが発生した時のための DRアカウント を追加しました。CI/CDアカウントも追加しました。

最後に、開発者アカウント群として、1人に1アカウントのサンドボックスアカウントを追加しました。

複数AWSアカウント

(39:00-)

複数AWSアカウントの長所と短所を見てみましょう。長所は次のとおりです。

セキュリティとリソースの分離を実現できる
障害発生を局所化できる
請求をアカウント単位に単純化できる

一方、短所は次のとおりです。

設定の作成と分配が必要になる
セットアップと運用にオーバーヘッドがある
アカウント間をまたぐセキュリティポリシーがますます複雑になる

ゴール

複数AWSアカウントの戦略を考えるにあたっては、原則またはゴールを考えるところから始めましょう。次の状態がゴールです。

自動化されている -- レプリケートを容易にするとともに、人間によるアクセスを減らす
スケーラブルである
できるだけセルフサービスにする
ブロッカーではなくガードレールを提供する
監査可能である
柔軟であること
- 新しいサービスや新しい方針が登場した時に、このモデル自体を変更できることが最も重要

アカウントセキュリティ - Day 1

ベースラインになる要求事項は、次のとおりです。

AWSアカウントクレデンシャル (Rootアカウント) を管理する
すべてのリージョンでCloudTrailを有効化する
エンタープライズRoleの割り当て
フェデレーションの利用: 組織への従業員の入退場と連携して動作させる
セキュリティアカウントや監査のためのクロスアカウントRoleの用意
アカウントに適用するアクションとコンディションの定義

どのアカウントを作成すべき？

Organizationマスターアカウント
エンタープライズ
- ロギングアカウント
- セキュリティアカウント
- Direct Connectアカウント
- 共有サービスアカウント
- 請求アカウント
ビジネスユニット
- サンドボックスアカウント
- Dev, Pre-Prod (Staging), Prod用アカウント
- その他、あなたの組織で必要なアカウント

これらの各アカウントについて、ざっくり見ていきましょう。

AWS Organizationsマスターアカウント

データセンターに接続しない
サービスコントロールポリシーを設定する
Consolidatedビリングの親アカウント
ボリュームディスカウント適用対象
プロビジョニングするリソースは最小限にする
アクセスを制限
設定作業が終わったらOrganization Roleを削除すること!

サービスコントロールポリシーとして、次のようなポリシーを作成しましょう。

CloudTrailのロギングの停止を禁止するポリシー
- cloudtrail:StopLogging
VPCへのInternet Gateway等のattachを禁止するポリシー
- ec2:AttachInternetGateway
- ec2:CreateInternetGateway
- ec2:AttachEgressOnlyInternetGateway
- ec2:CreateVpcPeeringConnection
- ec2:AcceptVpcPeeringConnection

ロギングアカウント

ログを格納するAmazon S3でバージョニングを有効にする
バケットのアクセスを制限し、MFA Deleteを有効にする
CloudTrail logs
セキュリティログ
正とする単一のソースにする
アクセスを厳しく制限する

セキュリティアカウント

(状況に応じてオプションとして) データセンターと接続する
セキュリティツールや監査ツールを導入する
CloudTrail、AWS Configを設定する
クロスアカウントのreadwrite Roleを許可する
アクセスを厳しく制限する

Direct Connect / Networkアカウントの作成

Direct Connectを利用する場合は、障害発生箇所を局所化するために専用のアカウントを作成します。

ネットワークチームが管理する
AWS Direct Connectやネットワークサービスを設定する
アクセスを制限する

共有サービスアカウントの作成

データセンターと接続する
DNSサービスを設置する
LDAP / Active Directoryを設置する
共有サービス用VPCを設置する
デプロイツールを設置する
- ゴールデンAMI
- パイプライン
スキャンインフラストラクチャ
- 非アクティブなインスタンス
- 正式でないタグ
- スナップショットライフサイクル
監視を設定する

請求用アカウント

Organizationマスターアカウントへのアクセスを減らす
ビリングレポートを生成する
メトリクスとレポートを利用する
最適化とReserved Instanceの管理をする
アクセスを制限する

内部監査用アカウントの作成

組織がPCIやHIPAAなどに準拠する必要がある場合は、内部監査用のアカウントも用意します。

コンプライアンス準拠
必要なログへのread-onlyアクセスを提供する
アクセスを制限する
参考セッション ENT324: Automating and Auditing Cloud Governance and Compliance in Multi-Account Environments

開発者用のサンドボックスアカウント

データセンターに接続しない
イノベーションのための場
月額使用料金の上限を設定する
自治性を重んじる
実験の場

ビジネスユニットのアカウント群

必要とされる分離レベルに基づいて設定する
開発のライフサイクルに合わせる

Devアカウント

開発とイテレーションを素早く回せるようにする
コラボレーションをおこなう
ソフトウェア開発ライフサイクルのステージに合わせる

Pre-Prod (Staging) アカウント

データセンターに接続する
本番とできるだけ同じように設定する
ステージングとしての利用
品質保証チームの利用
自動デプロイの実施

Prodアカウント

データセンターに接続する
本番アプリケーションをデプロイする
Pre-Prod環境からデプロイする
アクセスを厳しく制限する

チームの共有サービス用アカウント

有機的に成長することを想定する
ビジネスユニット/チームで共有する
Product-specificなサービスを設置する
データレイクを設置する
ビジネスユニット間で横断的に使われる共通ツールやサービスを設置する

チームのサンドボックスアカウント

データセンターに接続しない
データセンターからも接続されない
イノベーションや実験のための場として使う

サンドボックス / イノベーションアカウント間のパイプライン

開発者同士のコラボレーションのために、次のような使い方ができます。

開発者のサンドボックスアカウントからPoCアカウントへのアクセスを許可する
開発者のサンドボックスアカウントから、ほかのビジネスユニットの開発者アカウントへのアクセスを許可する

特別、例外的なアカウント

ここまで説明したフレームワークにこだわらず、柔軟に作成、設定する
必要なコンプライアンスや標準を守る (HIPAA、PCIなど)
必要に応じて、追加の分離やセキュリティコントロールを用意する (PII)
複雑なプラットフォームやプロダクトに対応する

マルチアカウントの方針

次のアカウントを作成しましょう。

Orgs
Logging
Security
Shared Service
Billing Tooling
Sandbox
Dev
Pre-Prod
Prod

次のステップ

やるべきことをリストにしました。

タグ付け戦略の定義
自動化戦略の定義
組織アカウントの作成
ロギングアカウントの作成
セキュリティアカウントの作成
共有サービス用アカウントの作成
請求ツール用アカウントの作成
開発者サンドボックス用アカウント (群) の作成

アクションプラン

より具体的なアクションプランは次のとおりです。チェックリストとして活用してください。

自動化戦略を定義する
タグ付け戦略を定義する
- AWS Tagging Strategies – AWS Answers
IPアドレス空間戦略を定義する
- データセンターや他のアカウント/VPCとの重複を避ける
組織マスターアカウントを作成する
ロギングアカウントを作成する
- CloudTrailとAWS Config用のバケットを作成する
- MFA deleteを有効化する
- バージョニングを有効化する
- バケットポリシーでアクセス制限を定義する
- ロギングアカウントにログを送信するように、rootアカウントでCloudTrailを有効化する
- 組織マスターの作成とロギングの間で発生するアクションに備えて、CloudTrailログをコピーする
セキュリティアカウントを作成する
- セキュリティアカウントとrootアカウント、ロギングアカウント間のクロスアカウントRoleを作成する
- read-onlyのRole
- readwriteのRole (できるだけ少ないパーミションで作成)
- CloudTrailを有効にして、ロギングアカウントにログを送る
- セキュリティチェックのためにセキュリティツールを導入し、Lambda関数を作成する
AWS Direct connectアカウントを作成する
請求ツール用アカウントを作成する
- 共通チェックリストを実施 (後述)
共有サービスアカウントを作成する
- 共通チェックリストを実施 (後述)
- DX/VPNとデータセンター間の接続を作成する
- 共通チェックリストを実施 (後述)
- 一般的なサービスを起動する
- Directory service
- DNS
ビジネスユニットアカウントの作成 (stage/devサイクルごとに)
- BU/チームのサンドボックスアカウントを作成する
- 共通チェックリストを実施 (後述)
- BU/チームのDevアカウントを作成する
- 共通チェックリストを実施 (後述)
- DX/VPNを経由してデータセンターのdevネットワークに接続する
- 共有サービスにVPCピアリングで接続する
- BU/チームのNon-Prod/Pre-Prodアカウントを作成する
- 共通チェックリストを実施 (後述)
- DX/VPNを経由してデータセンターのnon-prodネットワークに接続する
- ネットワークのプロビジョニング
- 共有サービスにVPCピアリングで接続する
- BU/チームのProdアカウントを作成する
- 共通チェックリストを実施 (後述)
- DX/VPNを経由してデータセンターのprodネットワークに接続する
- 共有サービスにVPCピアリングで接続する
開発者個人のサンドボックスアカウントを作成する
- クロスアカウントのセキュリティ用Roleを用意する
- 他の環境からの分離と非接続を維持する
- MFA/rootをセキュアに保管する
内部監査アカウントを作成する
- 共通チェックリストを実施 (後述)

共通チェックリスト

Rootクレデンシャルをセキュアに保管する
- MFAを使う
- 複雑なパスワードを使う
- ローテーションポリシーを策定する
まだであれば、Organizationsマスターアカウントにメンバーとして接続する
CloudTrailをすべてのリージョンで有効にして、ロギングアカウントにログを送信する
AWS Configを有効にして、ロギングアカウントに送る
セキュリティのためのread-onlyクロスアカウントRoleを作成する
セキュリティのためのreadwriteクロスアカウントRoleを作成する
(IPアドレス空間が重複しないように) VPCを作成する
アカウントでフェデレーションを有効にする
- 参考: SEC306: Choose Your Own SAML Adventure: A Self-Directed Journey to AWS Identity Federation Mastery
Roleとアクセスポリシーを定義する
連絡先情報として、グループメールと電話番号を使用する
共有サービスとともにVPCピアを利用する
すべてのアカウントにプリフィックスを利用した命名規則に関するポリシーを追加する
- 例: 「security*」で始まる名前のLambda関数へのアクセスを禁止する
CIS Foundations Benchmarkをレビューし、適切な対処をする

おわりに

マルチアカウント フレームワーク を標榜するだけあって、さまざまなユースケースを考慮したアカウントが登場しました。大量のアカウント種別に目を奪われますが、このセッションで重要なのは、レポートの前半でお伝えした「考え方」です。障害発生を局所化すること、コンプライアンスを準拠すること、それでいて開発者の利便性は守ること等の要求から、マルチアカウント管理の方針 をまず策定し、組織に合わせて具体的に必要なアカウントを計画していきましょう。

それでは、また。